Current visual design systems use a WYSIWYG (What You See Is What You Get) metaphor to provide a convenient, high-productivity and easy to use environment for the creation and editing of graphical applications and creations. Such creations or applications can include web sites, catalogs, presentations, e-shops, flow diagrams and as well as other application categories. These creations are deployed to systems which display them on a display screen, or to systems which print them.
A visual design system may integrate both static and dynamic content into the applications created in it. Static content may be stored locally and dynamic content may originate from a number of sources such as from the application itself, a database, an external dynamic data sources (or streams) such as a RSS feed or content generated by other users of the same system.
Visual design systems may be standalone systems (such as the Microsoft Visio diagram editor or the Microsoft PowerPoint presentation program), or may be embedded inside a larger editing system (such as the Microsoft Word AutoShape editor).
A designer using such a system may design a new application from scratch (starting with a blank screen), or may rely on predefined templates created by the application designer, by the system creator, or by the designer community. When a template is provided, the designer can customize it at will, adding, removing or modifying all elements of the template to create his or her version of the template.
Such applications generally consist of multiple pages. An application can include any number of pages and pages can typically be added or removed by the system designer and/or the end-user as required. Pages contain components which can be further classified as either atomic (those that cannot be broken down into sub-components) or container (which occupy a given screen area and can contain one or more further sub-components). Components may be fixed in shape and content, may be based on a content management system or may be based on user specified content such as a text area into which the designer enters text. Dynamic components can be based on external information (static or dynamic), such as a RSS feed displaying information from an external data source or the content of a given internet page.
Container components can be nested to a number of levels and can contain components of multiple types. Some containers are also limited to contain specific classes of contained components such as a photo album container which may only hold picture components. Component appearances and screen areas can be modified by moving, resizing, rotation and similar operations. Their appearance and behavior can also be modified by various modifiers, such as blurring and animation (e.g. the component has blurred edges, or appears on the screen by expanding from a single pixel, etc.) During the application creation and editing process, the content of a component may be entered and modified in a number of ways.
In visual design systems, typically the pages (containing the components) as well as the components themselves (container and atomic components) are often rectangles whose sides are parallel to each other and to the sides of the display screen. They are also parallel to the X and Y axes of the system on which the pages are being displayed or printed. In some cases, the components themselves are not axes-parallel rectangles. They may be a rotated rectangle, a combination of attached rectangles, or have a different shape altogether. In these cases, visual design systems (and their layout management element) typically handle the components using a per-component minimal enclosing axes-parallel rectangle which contains the irregularly-shaped component.
Components do not have to occupy mutually exclusive screen regions, and may in fact geometrically intersect each other. A component may also be situated completely within the boundaries of another component. The screen area overlap may be coupled with logical containment (i.e. the component “belongs” to a given container—and moves with the container wherever it goes), or be a mere geometrical overlap which is not based on any containment relationship. Whenever components intersect, a display priority attached to each component controls which component is displayed on top of which component. A visual design system typically employs a layout manager which manages component places, sizes, display order and related issues.
Visual design systems can be often be classified as absolute position or relative position systems (described in more detail herein below). In absolute positioning systems, the focus is on exact component positioning. The location of the components is defined as an absolute position value (x, y) relative to the containing entity, be it relative to the page itself or to a container containing the component. The position is typically expressed as an offset between the top left corner of the containing entity and the top left corner of the component.
In relative positioning systems, the focus is on the concept of flow or natural order. The system arranges components along a logical content flow, which typically corresponds to the reading order of the components whenever such an order is applicable. For example, an English language word processor is essentially a layout system for characters (and words) which uses the natural reading order of the English language (top to bottom and then left to right) to arrange the displayed characters and words. Another example is a blog editing system (such as the Wordpress blogging platform commercially available from wordpress.org), which arranges page elements (blog entries, talkbacks etc.) on a page according to a natural reading flow.
Thus, in a relative positioning system, the components are positioned relative to each other, so a component is displayed after (position-wise) the display of a previous component ends. Existing absolute and relative positioning systems both define a default screen or page size, which is used for all displayed pages. All relative positioning systems (and some absolute positioning systems) can increase this size as required to accommodate the addition of content to the page.
Visual design systems which use absolute positioning are best suited for exact layout and design of the displayed page. Such exact placement allows components to be properly sized, positioned and aligned on the displayed screen. For example, as illustrated in FIG. 1 components [a], [b], [c] and [d] are arranged on a page P. Components [e] and [f] are then added in the available space (page Q), so that all are properly aligned—[a], [e] and [c] in the first row, and [b], [f] and [d] in the second row—without the need to push components aside or to calculate the correct reading flow.
There are also two main types of absolute positioning systems, constraint based systems and anchor-based systems. The types are not mutually exclusive and systems can contain elements of both systems. In visual design systems, constraints and anchors can be specified explicitly by the designer (through the system user interface) or inferred automatically by the system based on existing component layout and information. In a constraint-based system, the designer defines dynamic mathematical constraints on the relationships between the components residing on the screen. In anchor-based systems, the dynamic layout is defined in terms of anchors set between components and framework elements, as well as between the components themselves.
Dynamic layout, the automatic adjustment of components according to their content to fit on a page, is known in the art. In existing systems, dynamic layout is typically present in relative (rather than absolute) positioning systems. Current methods available provide both manual and automatic solutions using standard methodologies such as anchoring. Dynamic layout involves the moving and resizing of components on the screen based on dynamic layout triggers. These triggers may include content changes, multiple target platforms (display of the application using different technologies on different viewing platforms), multiple screen sizes (display of the application using a number of displays which have different sizes and resolutions), dynamic data (use of components containing dynamic data which changes over time), end user changes and application initiated layout changes. Component moving and resizing may also cause dynamic layout changes (i.e. act as a trigger), although the system should provide a way to move and resize component without triggering dynamic layout (e.g. by providing separate visual editing modes with and without dynamic layout triggering).
Reference is now made to FIG. 2 which illustrates the implementation of dynamic layout on components [a] and [b] situated on a page W. As can be seen, component [a] is placed slightly above component [b] with a small separation between them. During editing, when component A is moved down, it begins to overlap and occlude component [b] as seen on page X. In such a scenario, it would be desirable to also move component [b] accordingly in order to view the content of component [b] as is shown on page Y or to even resize it accordingly, as shown on page Z, without losing sight of the content of component [b]. Such changes include not only modifications to the content of the displayed components ([a], [b]) but also modifications to their style and other display parameters, such as text size and font.
U.S. Pat. No. 5,796,401 to Wiener together with U.S. Pat. No. 7,554,689 to Tonisson and U.S. Pat. No. 7,634,725 to Nishikawa are believed to be representative of the prior art regarding dynamic layout.